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SPAM CONTROL FOR SHARING CONTENT ON MOBILE DEVICES 



CROSS-REFERENCE TO RELATED APPLICATION(S) 

[0001] This application is related to the following commonly assigned U.S. Patent 

Applications: U.S. Patent Application No. (attomey docket no. 

101948097US), filed April 9, 2004, entitled "Sharing Content on Mobile Devices" 

and U.S. Patent Application No. (attomey docket no. 

101 9481 01 US), filed April 9, 2004, entitled "Managing Differences in User Devices 
When Sharing Content on Mobile Devices," both herein incorporated by 
reference. 

BACKGROUND 

[0002] Content providers are increasingly offering content to subscribers of mobile 

wireless services. For example, mobile wireless service providers and others are 
offering wireless portals through which users of mobile devices can access 
content such as news, entertainment, and email services - the possibilities for 
content are endless. In addition, content providers that in the past have tailored 
their content for users of traditional web browsers are increasingly providing 
alternative formats for users of mobile devices. 

[0003] The mobile devices of today, while much advanced, are typically small with 

limited input capabilities and navigation capabilities. For this reason, content 
intended for users of such devices is sometimes subject to special formatting and 
protocols. Another problem content providers stmggle with is marketing their 
content to users of mobile devices. For example, because of the limited 
input/output capabilities of most wireless devices, it is difficult for the mobile end 
user to search for and identify new and interesting content. Very often, the best 
applications or content is made known by "word of mouth." For example, a friend 
or colleague may recommend a particular mobile application. In doing so. he or 
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she has to remember and describe where the content was found, which may not 
always be easy or practical. 
[0004] Another complication involves controlling the spread of unwanted or 

undesirable content that is propagated to a user's device, especially where users 
of mobile devices may be using valuable minutes or data allowances to view such 
unwanted content. Messages directing a user to view unwanted content are 
sometimes referred to as spam, and are typically sent for the purpose of 
marketing, other personal gain, or even harassment. 

BRIEF DESCRIPTION OF THE DRAWINGS 

[0005] Figure 1 is a block diagram showing an example of a system for sharing 

content under one embodiment. 
[0006] Figure 2 is a block diagram showing an example implementation of the 

mobile devices of Figure 1 . 
[0007] Figure 3 is a flow diagram showing a high-level transaction flow between 

various components of the system of Figure 1 . 
[0008] Figure 4 is a flow diagram showing an example of a spam filtering routine 

performed by the share content application of Figure 1 . 
[0009] Figure 5 is a flow diagram showing a privacy management routine 

performed by the share content application of Figure 1 . 
[0010] Figure 6 is a display diagram showing screens from which a user of the 

mobile content sender device of Figure 1 can view spam control messages when 

the user has attempted to share content with more than three users at one time. 
[0011] Figure 7 is a display diagram showing screens from which a user of the 

mobile content sender device of Figure 1 can view spam control messages sent 

when the user has attempted to exceed a threshold for sending content messages 

within a give time period. 
[0012] Figure 8 is a display diagram showing screens from which a user of the 

personal computer content sender device of Figure 1 can view spam control 

messages sent when the user has attempted to share content with more than 

three users at one time. 
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[0013] Figure 9 is a display diagram showing screens from which a user of the 

personal computer content sender device of Figure 1 can view spam control 
messages when the user has attempted to share content with more than three 
users at one time. 

[0014] Figure 10 is a display diagram showing screens from which the user of the 

recipient device may set global privacy settings. 

[0015] Figure 1 1 is a display diagram showing screens from which the recipient 

may identify privacy settings, including a blocked list used when the global privacy 
settings of Figure 10 are set to receive share content messages by default. 

[0016] Figure 12 is a display diagram showing screens from which the recipient 

may identify privacy settings, including an affirmative exceptions list when the 
global privacy settings of Figure 10 are set to block share content messages by 
default. 

[0017] In the drawings, the same reference numbers identify identical or 

substantially similar elements or acts. To facilitate the discussion of any particular 
element or act, the most significant digit or digits in a reference number refer to 
the figure number in which that element is first introduced (e.g., element 204 is 
first introduced and discussed with respect to Figure 2), 

[0018] A portion of this disclosure contains material to which a claim for copyright 

is made. The copyright owner has no objection to the facsimile reproduction by 
anyone of the patent document or patent disclosure (including Figures), as it 
appears in the U.S. Patent and Trademark Office's patent file or records, but 
reserves all other copyright rights whatsoever. 

DETAILED DESCRIPTION 

[0019] The invention will now be described with respect to various embodiments. 

The following description provides specific details for a thorough understanding of, 
and enabling description for, these embodiments of the invention. However, one 
skilled in the art will understand that the invention may be practiced without these 
details. In other instances, well-known structures and functions are not shown or 
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described in detail to avoid unnecessarily obscuring the description of the 
embodiments of the invention. 
[0020] It is intended that the terminology used in the description presented be 

interpreted in its broadest reasonable manner, even though it is being used in 
conjunction with a detailed description of certain specific embodiments of the 
invention. Certain terms may even be emphasized below; however, any 
terminology intended to be interpreted in any restricted manner will be overtly and 
specifically defined as such in this Detailed Description section. 

I. Overview 

[0021] The method and system described herein allows users of mobile devices to 

share content with other users via mobile messaging and other similar techniques, 
while at the same time minimizing the sending and receiving of unwanted share 
content messages (e.g., spam). In general, and as described more completely in 

U.S. Patent Application No. (attorney docket no. 101948097US) 

(incorporated herein by reference), the content sharing application makes sharing 
content easy for both users and content providers and helps to overcome 
difficulties associated with the limited input capabilities of small devices. For 
example, a user of a mobile device finds interesting content and wants to send it 
to a friend. The user then selects a share content link on the content page, which 
is provided by the content provider, who created the share content link based on 
an application program interface (API). The request to share content is sent to a 
share content application, which then sends a recipient identification form to the 
user's device. The user identifies the friend (or friends) by filling out and 
submitting the recipient identification form. The user's friend (or friends) then 
receives a content link via a message or alert (e.g., a WAP push message). The 
friend can then choose to act upon the received message by loading a URL 
provided in the message, or can ignore it or delete it. 

[0022] In addition to the capabilities referenced above, the share content 

application may include safeguards to help prevent the circulation of unwanted 
share content messages. For example, if a user attempts to send content to a 
large number of recipients in a short period of time (e.g., in a mass marketing 
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attempt), the user may be blocked from doing so. In addition, each recipient may 
set up privacy control features to prevent the receipt of unwanted messages. 

[0023] In some embodiments, receipt of unwanted messages can be avoided by 

hosting the content sharing application, at least in part, on mobile service provider 
servers configured for IP filtering. Such filtering restricts a user's access to the 
content sharing application unless the user is attempting to access the content 
sharing application from a mobile service provider's own WAP gateways (e.g., via 
a registered mobile device). When access is blocked in this way, selecting a 
content provider's share content link may not result in the user receiving a 
recipient information form from the share content application. This configuration 
generally prevents access by spam-generating users that do not have registered 
mobile devices, yet still allows legitimate users to access the share content 
application from a device other than the registered mobile phone by taking certain 
steps to get past the IP filtering. For example, the system may allow access from 
a PC or laptop if the user first establishes a network connection via a GPRS 
modem that is connected into the service provider network (which can then be 
tethered with a laptop, etc.). Each time a share content request is sent to the 
share content application, the share content application checks an ID of the user 
and verifies the user as a service provider subscriber before generating and 
sending the share content message to the recipient. 

[0024] Regardless of whether the above-described filtering technique is 

implemented, the share content application can implement additional techniques 
to prevent the sending of unwanted share content messages. For example, the 
content sharing application may limit the number of recipients a user can specify 
using a single recipient information form (e.g., three-recipient maximum). 

[0025] For users attempting to share content via an HTTP session (e.g., on a PC 

or laptop) the share content application may add a session variable in the HTTP 
session when the user requests to share content. More specifically, after the 
share content application receives the user's request to share content (e.g., by 
selecting a share content link), the share content application may generate the 
session variable (with a time stamp) in association with generating and sending a 
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recipient information form. The user device sends the session variable back to 
the share content application after the user has filled in and submitted the 
recipient information form. Before it generates or sends out a share content 
message to the recipient, the share content application checks the value of the 
session variable (and time stamp) and compares it with a user history to ensure 
that the same user has not exceeded a threshold level of share content requests 
within a given time frame. This prevents malicious use of scripts that repeatedly 
request to share content (e.g., by repeatedly selecting the form submission 
button). 

[0026] Another technique that limits the ability of more sophisticated spammers to 

share unwanted content (e.g., by writing scripts) involves providing a code (e.g., a 
sequence of numbers and letters) on the recipient information request forms. The 
form then requests that the user enter that code on a field in the recipient 
information request form. Because a script cannot read the code, this ensures 
that a user is entering the actual form and not a script. 

[0027] Yet another technique to prevent the receipt of unwanted share content 

messages includes providing an option for recipients to opt in or out of receiving 
share content messages from particular users (or all users). Such techniques 
may involve the use of global privacy settings and/or privacy lists (e.g., blocked 
sender list, allowed sender list, etc.). Thus, privacy management for the recipients 
can be global or user-specific. For example, John can opt out of receiving these 
alerts from all or any users, while Jill may want to receive such alerts only from a 
few of her friends, whereas Jack blocks only a select list of users for sending such 
alerts. 

II. Representative Svstem 
[0028] Figure 1 and the following discussion provide a brief, general description of 

a suitable environment in which the invention can be implemented. Although not 
required, aspects of the invention are described in the general context of 
computer-executable instmctions, such as routines executed by a general- 
purpose computer (e.g., a server computer, wireless device, or personal/laptop 
computer). Those skilled in the relevant art will appreciate that the invention can 
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be practiced with other communications, data processing, or computer system 
configurations, including Internet appliances, hand-held devices (including 
personal digital assistants (PDAs)), wearable computers, all manner of cellular or 
mobile phones, embedded computers (including those coupled to vehicles), multi- 
processor systems, microprocessor-based or programmable consumer 
electronics, set-top boxes, network PCs, mini-computers, mainframe computers, 
and the like. Indeed, the terms "computer," "host," and "host computer" are 
generally used interchangeably and refer to any of the above devices and 
systems, as well as any data processor. 

[0029] Aspects of the invention can be embodied in a special purpose computer or 

data processor that is specifically programmed, configured, or constructed to 
perform one or more of the computer-executable instructions explained in detail 
herein. Aspects of the invention can also be practiced in distributed computing 
environments where tasks or modules are perfomned by remote processing 
devices, which are linked through a communication network. In a distributed 
computing environment, program modules may be located in both local and 
remote memory storage devices. 

[0030] Aspects of the invention may be stored or distributed on computer-readable 

media, including magnetically or optically readable computer disks, such as 
microcode on semiconductor memory, nanotechnology memory, organic or optical 
memory, or other portable data storage media. Indeed, computer-implemented 
instructions, data structures, screen displays, and other data under aspects of the 
invention may be distrifcfuted over the Internet or over other networks (including 
wireless networks), on a propagated signal on a propagation medium (e.g., an 
electromagnetic wave(s), a sound wave, etc.) over a period of time, or may be 
provided on any analog or digital network (packet switched, circuit switched, or 
other scheme). Those skilled in the relevant art will recognize that portions of the 
invention reside on a server computer, while corresponding portions reside on a 
client computer, such as a mobile device. 

[0031] Referring to Figure 1, a system 100 on which the content sharing scheme 

can be implemented provides various networked components. These 
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components include one or more content providers 102, a share content 
application 104 and database 106, a wireless portal 108 and database 110, and, 
optionally, an address book application 112 and database 114. The system 100 
also includes various end user components, including content sender devices 116 
(e.g., mobile device, laptop, PC, etc., with browser), content recipient devices 118 
(e.g., WAP-enabled mobile device, SMS-enabled mobile device, etc.), and cross- 
carrier recipient devices 120. Details regarding the functionality of the 
components of Figure 1 are described in detail below. 

[0032] These various components communicate via one or more networks 122. 

For example, the system 100 may include a wireless network. Examples of 
wireless telecommunication networks include UIVITS (universal mobile 
telecommunication system), GSM (global system for mobile communications) 
(possibly including GPRS (general packet radio service), EDGE (enhanced data 
rates for GSM evolution), etc.). CDMA (code division multiple access), IS-136. 
analog, etc. The system may also include various wired or partially wired 
networks, such as the Internet, a wired LAN (local area network), or even a public 
switched telephone network (PSTN). While not all types of networks are 
described herein, the invention may be implemented within the framework of 
many types of networks. 

[0033] In some embodiments, the share content application 104, along with the 

various gateway components, is configured to communicate within more than one 
of the above described communication networks. For example, users may access 
the share content application 104 from a personal computer or laptop via a wired 
or partially wired public communication network (i.e., the Internet). It can also be 
accessed via a telecommunication network, such as one of the wireless or wired 
networks described above. 

[0034] To facilitate and manage networi< communications, the system 100 may 

include various communication gateways and related applications. For example, 
the share content application 104 and the content sender devices 116 
communicate via a WAP gateway/proxy 124, and a push proxy gateway 128. 
Content recipient devices 118 may receive WAP push messages via the push 
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proxy gateway 128 and a short message peer-to-peer gateway 130. Cross-carrier 
content recipient devices 120 may receive messages via a short message peer-to- 
peer gateway 130 used in conjunction with a cross-carrier service application 132. 
In general, any "cross-carrier" component refers to a component operated by a 
telecommunications carrier that differs from a telecommunications carrier 
operating the other components of Figure 1 . 

[0035] Via this combination of networks and gateways, the share content 

application 104 may establish communication links on many different types of 
networks, with many different types of devices, including cross-carrier devices. In 
some embodiments, the share content application 104 runs on, or in association 
with, the system of a wireless service provider or wireless carrier. Accordingly, 
many of its capabilities may be based on information associated with its 
subscribers (customers). Some of these capabilities include tracking share 
content requests made by users. 

[0036] Figure 2 shows a block diagram of a typical mobile communication device 

200, such as a mobile handset. This device is representative of both the content 
sender device 116 and content recipient devices (118 and 120) of Figure 1, While 
a mobile phone is shown as the mobile communication device in Figure 1, those 
skilled in the relevant art will appreciate that the invention can be practiced with 
other devices and configurations, including Internet appliances, hand-held 
devices, wearable computers, multi-processor systems, microprocessor-based or 
programmable consumer electronics, set-top boxes, PDAs, portable laptop 
computers, and the like. The term "mobile device" is intended to include all such 
devices. 

[0037] The mobile device 200 has one or more internal or external antennas 202 

for receiving and transmitting electromagnetic signals such as radio frequency 
signals. A transceiver 204 is connected to the antenna(s) 202 and typically 
provides modulation and demodulation of the transmitted and received signals, 
respectively. A processor unit 206 connected to the transceiver 204 may 
comprise a signal processor, microprocessor, ASIC, or other control and 
processing logic circuitry. The processor unit 206 may perform signal coding, data 
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processing, input/output processing, power control, and other functions necessary 
for implementing a mobile communication device. A customer may provide input 
to the processor unit 206 via a keypad 208, microphone 210, or display/touchpad 
212. In turn, the processor unit 206 may provide information to the customer via 
the display/touchpad 212 or a speaker 214. 
[0038] The processor unit 206 may access information from, and store information 

in, a nonremovable memory 216 or a removable memory 218. The nonremovable 
memory 216 may consist of RAM, ROM, a hard disk, or other well-known memory 
storage technologies. The removable memory 218 may consist of Subscriber 
Identity Module (SIM) cards, which are well known in GSM communication 
systems, or other well-known memory storage technologies, such as "smart 
cards." Applications 220 such as wireless content browser applications and 
address book applications could be implemented in either the removable memory 
218 or the nonremovable memory 216. 

III. Application Program Interface and Platforms 
[0039] In some embodiments, the share content application may be associated 

with an API (application program Interface) that allows content providers to easily 
create "links" or other functionality that facilitates sharing of content and 
applications. In some embodiments, share links may be placed within the content 
itself, or be somehow otherwise available through the content or application. Such 
links may be in the form of an HTTP GET request, which may use the URL itself 
to send information (e.g., application name, application URL, return URL, etc.) to 
the share content application. An example of such a request is as follows: 

http: //wireless .mobile .wirelesscarrier .net /p2p?msisdn=2 06555 1212 &app_name 
=CoolGameScapp_url=http : //www . coolgame . com/ coolgame . wml&return_url=http : / / 
www. coolgame . com 

[0040] In the above example, the URL begins with an indication of the protocol in 

use ("http") followed by the host name "wireless.mobile.wirelesscarrier.net" 
followed by the "p2p" path name. The information provided following the "?" is the 
information sent as part of the GET request. In the above example, this 
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information includes tfie IVISISDN of tlie content sender device (2065551212) and 
the application name (name for the content, "Cool Game"), the application URL 
(www.coolgame.com/coolgame.wml), and a return URL (www.coolgame.com). 
The application URL takes the friend or recipient to content upon receipt of the 
message, while the return URL takes the user back to the content after the share 
content request process is complete. The application URL and the return URL 
may be the same or different. For example, if a content provider wants to route all 
new visitors to a home page, the application URL may be the home page, 
whereas the return URL may be the page from which the user selected the share 
content link. In the above example, the information passed in the GET request 
may be configured statically, with only the MSISDN added at run time. Depending 
on the technique used for sharing the information, other information can be added 
to the GET request at run time, such as the sender's name/message, the friend's 
MSISDN, etc. Some of the parameters that can be passed in a GET request are 
described in more detail in Table 1 below. 



Parameter 


Description 


uri 


The URL of the content that is being shared. This is also the 
generic URL in case the surl is specified. In some 
embodiments, this parameter is needed when surl is not 
specified. 


surl 


The specific URL of the content that is being shared. The 
friend receives the surl in the push message when the friend's 
device belongs to the user's device class. If this parameter is 
not specified irrespective of the device of recipient, urI is 
shared. 


title 


Title of the content to be shared 


returnurl 


The URL to which the sender is returned after the user is done 
sharing the content. When returnurl is not specified, surl is 
used. When surl and returnurl are not specified, the value of 
urI is used to return the user. 
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Parameter 


Description 


cc 


Indicates whether the content provider is interested in sending 
the SMS message to a cross-carrier friend of the user. If this 
value is set to "y" an SMS message is sent to cross-carrier 
friends with the value for uh in the message. A missing cc 
parameter or any other value other than "y" would mean this 
URL will not be shared with the cross-carrier friend. 



Table 1 



IV. Svstem Flows 

[0041] Figures 3 through 5 are representative flow diagrams that show processes 

that occur within the system of Figure 1 . These flow diagrams do not show all 
functions or exchanges of data but, instead, provide an understanding of 
commands and data exchanged under the system. Those skilled in the relevant 
art will recognize that some functions or exchanges of commands and data may 
be repeated, varied, omitted, or supplemented, and other aspects not shown may 
be readily implemented. For example, while not described in detail, a message 
containing data may be transmitted through a message queue, over HTTP, etc. 

[0042] The flows represented in Figures 3 and 4 are high-level flows in which the 

entire transaction is shown from initiation to completion. Some of the individual 
processes or subtransactions are described in more detail in the Figures that 
follow. The various entities that may be involved in the transaction are also 
depicted in Figure 1 and include the content sender device 116, the content 
provider 102, the share content application 104, the wireless portal 108, the 
address book application 112, various components of the push proxy gateway 
128, and the content recipient device 118. 

[0043] Referring to Figure 3, a share content transaction 300 for WAP-enabled 

devices is shown from initiation to completion. At a subtransaction 302 a user of 
the content sender device 116 selects to share content provided by the content 
provider 102. At a subtransaction 304 the share content application 104 receives 
various parameters associated with the content to be shared. The types of 
information that may be included as parameters are described in more detail 
above in the section entitled "Application Program Interface and Platfomris." In 
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some embodiments, the parameters are sent in the form of an HTTP GET request 
that is created by the content provider 102 and accessed by the user of the 
content sender device 1 16 as a hyperlink on a content page. At a subtransaction 
306, the share content application 104 receives the share content request and 
authenticates the user of the content sender device 116. In the case where users 
are selecting to share content from a PC, the portal may provide the appropriate 
user information so that the share content application 104 can perform this 
verification subtransaction. 
[0044] Once the user is authenticated, at a subtransaction 310, the content sender 

device 116 receives a user input form from the share content application 104. If 
authentication of the user fails, the user sees an error message on the device 
instead of the user input form. The user may also see this error message if the 
content provider 102 fails to provide certain parameters (e.g., uri or surl, described 
below). 

[0045] At a subtransaction 312, the user performs an optional address book 

lookup function via the share content application 104. At a subtransaction 314, 
the share content application 104 may optionally invoke the address book 
application 112, which, at a subtransaction 316, performs a query of the address 
book (AB) database 114 and provides results to the share content application 104. 
At a subtransaction 318, the share content application 104 sends results of the 
address book lookup to the content sender device so it can be displayed to the 
user and the user can select or enter the appropriate entries. 

[0046] After the user has completed the input form, at a subtransaction 320, the 

content sender device 116 submits the completed form to the share content 
application 104. At a subtransaction 322, the share content application 104 may 
check for spam, a process that is described in more detail in Figures 4-12, which 
are described in more detail below. At a subtransaction 324, the share content 
application 104 checks the recipient status to determine whether each specified 
content recipient device 118 subscribes to a service associated with the share 
content application 104 or is a cross-carrier recipient. At this transaction, the 
share content application 104 may also check for information about the recipient 
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devices to determine whether they may be compatible with the content or 
applications to be shared, a process that is described in more detail in U.S. Patent 

Application No. (attorney docket no. 101948101 US) 

(incorporated by reference). 

[0047] At a subtransaction 326, a "recents" list may be updated with the latest 

recipient information. This list may be stored at the share content application 104 
and may include a list of names or MSISDNs (mobile station ISDN number) most 
recently contacted by the user. 

[0048] At a subtransaction 328, the share content application 104 communicates 

with various components of the push proxy gateway 128 to establish a WAP push 
message for each of the eligible content recipient devices 118. In some 
embodiments, a single push proxy gateway address will resolve users on all 
available gateways available in the network. At a subtransaction 330. the WAP 
push message(s) are sent to the content recipient device(s) 118. In this way, the 
user of a content recipient device 1 18 is directed to the content (e.g., a URL). At a 
subtransaction 332, the share content application 104 sends a status page to the 
content sender device 116. This may include return URL information so that the 
user can automatically be taken back to the content that he or she originally 
selected for sharing. 

[0049] Referring to Figure 4, a call flow for a routine 400 implemented at the share 

content application controls spam, while still allowing users to access the share 
content application from a device other than a registered mobile device (e.g., an 
Internet-enabled PC with a standard web browser). At block 402 the user submits 
a recipient information form received after the user selected a link on a content 
provider application or page. The recipient information form is configured to allow 
the user to identify recipients to receive selected content. When filled in by the 
user, the recipient information form includes information identifying one or more 
recipients. Alternatively, the form may come pre-filled-in and may contain a list of 
"recent" recipients identified by the user in previous recipient information fomris. In 
some embodiments, the recipient information form may limit the number of 
recipients that the user can identify using the single form. In some embodiments, 
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the recipient information form itself may not limit the number of recipients. 
Instead, the routine 400 performs a check after the user submits the form to make 
sure a threshold limit of recipients is not exceeded (e.g., three recipients per 
form), as illustrated in Figures 6 and 8. 
[0050] At decision block 404, the routine 400 checks whether, within a given short 

time frame (e.g., five minutes), the same user submitted a recipient information 
form associated with the same content (e.g., content having the same title or URL 
parameters). The routine 400 may use a time-stamped session variable 
generated in association with the recipient information form to implement this 
check. For example, the user device may send the session variable back to the 
share content application after the user has filled in and submitted the recipient 
information form. The routine 400 checks the value of the session variable (and 
time stamp) and compares it with a user history to ensure that the same user has 
not exceeded the threshold level of share content requests. If at decision block 
404 the routine 400 identifies that the user submitted a request for sharing the 
same content in the given time frame, the routine continues at block 406 where It 
blocks the share content message to be sent to the recipient. In some 
embodiments, at block 406, the routine 400 also sends a confirmation or success 
message to the user under the assumption that, in light of the given conditions 
(short time period/same content), the user is indeed sending spam. Because the 
user does not know that the spam messages are not reaching the recipients, the 
user will not be encouraged to employ additional measures to send the messages. 
If, however, at decision block 404 the routine 400 identifies that the user did not 
send a similar request within the given time frame, the routine continues at 
decision block 408. 

[0051] At decision block 408, the routine 400 checks if the user sent more than a 

threshold number (e.g., 100) of share content messages within a given time frame 
(e.g., one calendar day). In general, this check detects if the user is using an 
automated script to generate the share content messages. If at decision block 
408 the user exceeded the threshold number of messages in the given time 
frame, the routine 400 continues at block 410 where it blocks the share content 
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message to be sent to the recipient, and sends an error message to the user. If, 
however, at decision block 408 the user did not exceed the threshold number of 
messages to be sent in the given time frame, the routine 400 continues at 
decision block 412. 

[0052] At decision block 412, the routine 400 checks if the user sent more than a 

threshold number (e.g., 15) of share content messages within the given short time 
frame (e.g., 60 seconds). If at decision block 412 the routine 400 Identifies that 
the user did exceed the threshold number of share content messages during the 
given time frame, the routine continues at block 414 where it blocks the share 
content message to be sent to the recipient and sends an error message to the 
user. If, however, at decision block 412, the routine 400 identifies that the user 
did not send a similar request within the given time frame, the routine continues at 
decision block 416, where it generates the share content message and the user 
receives confirmation that the message was sent. 

[0053] The spam control thresholds that the share content application uses in 

making its spam checks may be controlled by configuration parameters set by 
system administrators, or even automatically (e.g., thresholds may change at 
certain times of day, assuming that most legitimate users will operate during 
waking hours, etc.). 

[0054] The share content application may use a data table to keep track of 

messages initiated by the user. For each share content message initiated by the 
user, the data table may track a submission number, a recipient identifier MSISDN 
(e.g., a sent date, a content title, and a content URL value). The table may have a 
purging mechanism, which clears the data table on a periodic basis (e.g., daily). 
In some embodiments, the time stamp information associated with a given 
recipient information form is checked against values in such tables. The data 
stored in the table may allow the application to calculate a "spam score" for the 
user for a given time period (e.g., one minute, 15 seconds, one day, etc.). 

[0055] Regardless of whether spam control techniques such as those described 

above and others are implemented, some users may find it undesirable to receive 
share content messages or alerts, even from friends. Accordingly, the system 
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may facilitate privacy management options (e.g., opt in/opt out) that recipients 
themselves can control. Referring to Figure 5, the share content application may 
provide a privacy management framework and routine 500. At block 502, the user 
submits a recipient information form received after the user selected a link on a 
content provider application or page. The form is configured to allow the user to 
identify recipients to receive selected content. When filled in by the user, the 
recipient information form includes infonnation identifying one or more recipients. 
Alternatively, the form may come pre-filled-in and may contain a list of "recent" 
recipients identified by the user in previous recipient information forms. 

[0056] At block 504, the share content application performs one or more spam 

check routines, such as the spam check routine 400 of Figure 4. At decision block 
506 the routine 500 checks the recipient's global privacy settings. If at decision 
block 506 the recipient's global privacy settings generally allow for content sharing 
messages, the routine 500 allows the message to pass to the next check and 
proceeds to decision block 508 (check for negative exceptions). However, if at 
decision block 506 the recipient's global privacy settings generally do not allow for 
content sharing messages, the routine 500 blocks the message and continues at 
decision block 51 0 (check for affirmative exceptions). 

[0057] At decision block 508, the routine 500 checks if there is a negative 

exception for receiving messages from the user initiating the share content 
message. This may include checking a "blocked list" created by the recipient to 
check if the user is included. Alternatively, the recipient may block certain types of 
content, rather than messages from particular users. If there is a negative 
exception associated with the user (or content), the routine 500 continues at block 
514, where the routine does not send the message to the recipient. At block 514, 
the routine 500 may also send a status message to the device of the user (e.g., 
"message sent" or "message not sent"). Note that in some embodiments, the op- 
out preferences of a recipient are not revealed to the user, meaning that it will 
appear to the user that the recipient received the share content message, 
whereas in actuality it was blocked. 
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[0058] If at decision block 508 there is no negative exception associated with the 

user (or content), the routine 500 continues at block 512, where the share content 
application sends the message to the recipient. 

[0059] From decision block 510, the routine 500 checks if there is an affirmative 

exception for receiving messages from the user (or for the particular content being 
sent. If at decision block 510 an affirmative exception exists, the routine continues 
at block 512 where the share content application sends the message to the 
recipient. However, if at decision block 508 the user initiating the message is not 
on the recipient's affinmative exception list, the routine continues at block 514 
where the share content application does not send the message to the recipient 
and where the share content application sends a status message to the device of 
the user. 

[0060] The share content application may collect a recipient's privacy settings, 

including global privacy settings, in a data table. For example, if a recipient's 
global privacy flag is set to a value of "0" or "false," then the recipient wants to 
receive share content messages. In contrast, if the global privacy flag is set to a 
value of "1" or "true," then the recipient does not want to receive share content 
messages. If no record is present for the recipient, then the default is to allow 
share content messages to be sent to recipient. The data table may also store 
information about identifiers (e.g., MSISDNs) associated with recipient devices, as 
well as identifiers associated with users or user devices. In this way, exceptions to 
the global or default settings can be implemented (e.g., as described with respect 
to blocks 506 to 514 of Figure 5). Such techniques can be implemented even 
where users and recipients are not registered users of the service provider 
associated with the share content application. 

[0061] The opt-in/opt-out privacy management approaches described above 

provide flexibility for users in managing their privacy preferences. However, one 
skilled in the art would understand that these and other privacy management 
techniques could be implemented without departing from the scope of the 
invention. For example, users may manage privacy by defining the types of 
content that they would or would not like to receive. Likewise, users may manage 
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privacy by restricting content from certain content providers. In some 
embodiments a range of opt-in/opt-out options may be made available to users via 
a portal preferences screen or via other means. 

V. User Interface 

[0062] As described in the flow charts above, the content sharing system may 

include various user screens, views, and other interfaces that allow users to share 
content, view spam control limitations, and define privacy settings. Examples of 
such screens are described with respect to Figures 6 through 12. While only 
certain examples are given, a person skilled in the art will appreciate that many 
other interfaces could be implemented without departing from the scope of the 
invention. The terms "screen," "window," "web page," and "page" are generally 
used interchangeably herein. The pages described herein may be implemented 
using, for example, WML (wireless markup language), XHTML (extensible 
hypertext markup language), XML (extensible markup language), or HTML 
(hypertext markup language). In some embodiments, WML and XHTML decks 
offer similar functionality but may differ with respect to style guide and design 
requirements between the two languages (use of color, icons, etc.). The look and 
feel of WML pages are primarily text-based, with underlining used to highlight 
clickable links. XHTML is a richer development language, allowing the mobile 
device to present content that may stand out on many different levels. For 
example, XHTML may allow the use of front and background colors, holding, and 
icons. 

[0063] The screens or web pages provide facilities to receive input data, such as a 

form with fields to be filled in, pull-down menus, or entries allowing one or more of 
several options to be selected, buttons, sliders, hypertext links, or other known 
user interface tools for receiving user input. While certain ways of displaying 
information to users is shown and described with respect to certain Figures, those 
skilled in the relevant art will recognize that various other alternatives may be 
employed. The pages or screens are stored and/or transmitted as display 
descriptions, as graphical user interfaces, or by other methods of depicting 
infomnation on a screen (whether personal computer, PDA, mobile telephone, or 
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other) where the layout and information or content to be displayed on the page is 
stored in memory, a database, or other storage facility, 
[0064] When implemented as web pages or wireless content, the screens are 

stored as display descriptions, graphical user interfaces, or other methods of 
depicting information on a computer screen (e.g., commands, linlcs, fonts, colors, 
layout, sizes and relative positions, and the like), where the layout and information 
or content to be displayed on the page is stored in a database. In general, a "link" 
refers to any resource locator identifying a resource on a network, such as a 
display description provided by an organization having a site or node on the 
network. A "display description," as generally used herein, refers to any method 
of automatically displaying information on a computer screen in any of the above- 
noted formats, as well as other formats, such as email or character/code-based 
formats, algorithm-based formats (e.g., vector generated), or matrix or bit-mapped 
formats. While aspects of the invention are described herein using a networked 
environment, some or all features may be implemented within a single-computer 
environment. 

[0065] In general, for ease in describing features of the invention, aspects of the 

invention will now be described in terms of a user interacting with the share 
content application server computer via his or her user computer or mobile device. 
As implemented, however, the user computer receives data input by the user and 
transmits such input data to the server computer. The server computer then 
queries the database, retrieves requested pages, performs computations, and/or 
provides output data back to the user computer, typically for visual display to the 
user. 

[0066] Referring to Figure 6, when the user attempts to share content with more 

than three users at one time using a single form, the user may receive an error 
message, as displayed in an error message screen 602. The error message 
screen 602 specifies that the user may only share a page with up to three friends 
at one time. From the error message screen 602 the user can select an OK 
option 604, which results in the display of a recipient identification form screen 
606. From the recipient identification form screen 606, the user may specify a 
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new set of users or edit the original set. From the error screen 602, the user can 
also select a help option 608, which will take the user to a help screen 610 that 
specifies that the user may not share a page or content with more than three 
friends at once but has specified more than three recipients. The help screen 610 
also specifies that if the user does not want to share the page with additional 
people, the user can select a "share with others" option (not shown) after sending 
the message, enabling the user to enter additional recipients. 

[0067] Referring to Figure 7, if the user exceeds a limit for sharing content within a 

specified time period, an error message screen 702 is displayed to the user. The 
error message screen 702 contains a message that the user has exceeded the 
limit for sharing content, and that the user may try again the next day. From the 
error message screen 702, the user can select an OK button 704. which takes the 
user back to a homepage screen 706. Alternatively, the user can select a help 
option 708, which then takes the user to a help screen 710 that specifies that the 
user cannot share any more pages at this time. The error message screen 702 is 
displayed when the user attempts to share spam or othenA/ise exceeds allotted 
thresholds. However, as noted above with respect to Figures 4 and 5, in some 
situations the share content application may intentionally fail to provide the error 
message screen in hopes that, if the user thinks the recipients are receiving the 
spam messages, the user will not take alternative measures. 

[0068] Refenring to Figure 8, users of PCs or other devices may also receive error 

or status messages when attempting to send content. For example, as shown on 
a recipient information form screen 802, a user is attempting to send a message 
to more than three recipients by inputting more than three numbers into a text field 
804. When the user selects the send button 806, an error screen 808 is displayed 
that specifies that the user can only share with up to three friends at once. From 
the error screen 808, the user can delete one or more of the phone numbers 
entered in the text field 804 so that the three phone number limit is not exceeded. 

[0069] Referring to Figure 9, in any number of situations, such as those described 

above with respect to Figures 4 and 5, a user may receive an error message 900 
for attempting to send more than a threshold number of messages during a 
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specified time period, even where multiple recipient infonmation forms are used. 
In the embodiment illustrated in Figure 9, the error message 900 is displayed on a 
web browser screen of a PC, indicating that a threshold for sending share content 
messages has been exceeded. While not shown, a similar error message screen 
may be displayed on a mobile device. 

[0070] Referring to Figure 10, a user can set his or her global block message 

settings from a series of one or more privacy management screens (1002 and 
1004). Screen 1002 shows that the user currently blocks share content messages 
and describes that, if the user would like to receive messages, he or she can 
select an accept option 1006. Screen 1004 shows that the user currently accepts 
share content messages. From this screen, if the user no longer wants to receive 
such messages, the user can select a block option 1008. 

[0071] Referring to Figure 11, when a user has instated global privacy 

management settings that allow the user to receive share content messages 
unless blocked, the privacy management settings allow the user to specify a list of 
blocked senders 1102 that the share content application may use for exceptions. 
In the illustrated embodiment, the user can go back and modify the blocked list at 
a later time by selecting an update list option 1104. In addition, the selection of 
blocked individuals may be facilitated via an address book application, such as the 
address book application 112 of the system of Figure 1. Access to the address 
book application may involve the selection of a look up contact option 1 106. 

[0072] Referring to Figure 12, when a user has instated global privacy 

management settings that prevent the user from receiving certain share content 
messages, the privacy management settings allow the user to specify an accept 
list 1202 of allowed senders that the share content application may use for 
exceptions. In the illustrated embodiment, the user can go back and modify the 
blocked list at a later time via an update list option 1204. Access to the address 
book application may also be provided via a look up contact option. 

VI. Conclusion 

[0073] Unless the context cleariy requires otherwise, throughout the description 

and the claims, the words "comprise," "comprising," and the like are to be 
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construed in an inclusive sense as opposed to an exclusive or exhaustive sense; 
that is to say, in the sense of "including, but not limited to." Additionally, the words 
"herein," "above," "below" and words of similar import, when used in this 
application, shall refer to this application as a whole and not to any particular 
portions of this application. When the claims use the word "or" in reference to a 
list of two or more items, that word covers all of the following interpretations of the 
word: any of the items in the list, all of the items in the list, and any combination of 
the items in the list. 

[0074] The above detailed description of embodiments of the invention is not 

intended to be exhaustive or to limit the invention to the precise form disclosed 
above. While specific embodiments of, and examples for, the invention are 
described above for illustrative purposes, various equivalent modifications are 
possible within the scope of the invention, as those skilled in the relevant art will 
recognize. For example, while processes or blocks are presented in a given 
order, alternative embodiments may perform routines having steps or employ 
systems having blocks in a different order, and some processes or blocks may be 
deleted, moved, added, subdivided, combined, and/or modified. Each of these 
processes or blocks may be implemented in a variety of different ways. Also, while 
processes or blocks are at times shown as being performed in series, these 
processes or blocks may instead be performed in parallel or at different times. 
Where the context permits, words in the above Detailed Description using the 
singular or plural number may also include the plural or singular number, 
respectively, where the context permits. 

[0075] The teachings of the invention provided herein can be applied to other 

systems, not necessarily only the system described herein. The elements and acts 
of the various embodiments described above can be combined to provide further 
embodiments. 

[0076] All of the above patents and applications and other references, including 

any that may be listed in accompanying filing papers, are incorporated herein by 
reference. Aspects of the invention can be modified, if necessary, to employ the 
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systems, functions, and concepts of the various references described above to 
provide yet further embodiments of the invention. 

[0077] These and other changes can be made to the invention in light of the above 

Detailed Description. While the above description details certain embodiments of 
the invention and describes the best mode contemplated, no matter how detailed 
the above appears in text, the invention can be practiced in many ways. Details of 
the content sharing system and spam control and privacy management 
techniques may vary considerably in their implementation details, while still being 
encompassed by the invention disclosed herein. As noted above, particular 
terminology used when describing certain features, or aspects of the invention 
should not be taken to imply that the terminology is being re-defined herein to be 
restricted to any specific characteristics, features, or aspects of the invention with 
which that terminology is associated. In general, the terms used in the following 
claims should not be construed to limit the invention to the specific embodiments 
disclosed in the specification, unless the above Detailed Description section 
explicitly defines such temris. Accordingly, the actual scope of the invention 
encompasses not only the disclosed embodiments, but also all equivalent ways of 
practicing or implementing the invention under the claims. » 

[0078] While certain aspects of the invention are presented below in certain claim 

forms, the inventors contemplate the various aspects of the invention in any 
number of claim forms. For example, while only one aspect of the invention is 
recited as embodied in a computer-readable medium, other aspects may likewise 
be embodied in a computer-readable medium. Accordingly, the inventors reserve 
the right to add additional claims after filing the application to pursue such 
additional claim forms for other aspects of the invention. 
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